Distributed scalable cryptographic access contol

ABSTRACT

Published resources are made available in an encrypted form, using corresponding resource keys, published through resource key files, with the publications effectively restricted to authorized peer systems only by encrypting the resource keys in a manner only the authorized peer systems are able to recover them. In one embodiment, the resource keys are encrypted using encryption public keys of the authorized peer systems or the groups to which the authorized peer system are members. In one embodiment, the encryption public keys of individual or groups of authorized peer systems are published for resource publishing peer systems through client and group key files respectively. Group encryption private keys are made available to the group members through published group key files. Further, advanced features including but not limited to resource key file inheritance, password protected publication, obfuscated publication, content signing, secured access via gateways, and secured resource search are supported.

RELATED APPLICATION

[0001] This application claims priority to provisional applications

[0002] (a) No. 60/279,287, entitled “Scalable and Secure Access ControlFor Peer Resources via Encryption and Cached Keys”, filed on Mar. 27,2001;

[0003] (b) No. 60/306,490, entitled “A Distributed ScalableCryptographic Access Control Infrastructure”, filed on Jul. 7, 2001; and

[0004] (c) No. 60/309,340, entitled “A Distributed ScalableCryptographic Access Control Infrastructure”, filed on Jul. 31, 2001.

[0005] The specifications of these provisional applications are herebyincorporated by reference.

BACKGROUND OF THE INVENTION

[0006] 1. Field of the Invention

[0007] The present invention relates to the field of security indistributed systems. More specifically, the present invention relates tomethods and systems associated with enforcing access privileges andrestrictions in decentralized networks, and their applications to thesecure publication of content in peer-to-peer networks.

[0008] 2. Background Information

[0009] Recent advances in broadband technology are prompting a shiftfrom the established client-server model of the World Wide Web to aparadigm in which end-user machines can interact directly with eachother. In this new model, called peer-to-peer computing, interactionsbetween users are no longer constrained to go through a centralizedserver, but can take place directly between end-user machinesthemselves.

[0010] Interactions that are better carried out in a peer-to-peerfashion include the transfer of large volumes of data (such as images,music files, or video clips) or highly volatile information (such asoffice documents being edited by several people at once), anddistributed applications that run on multiple machines (such asreal-time distributed games where nodes use Web services to interactwith each other, or business-to-business applications that are builtaround a Web services interaction model). Peer-to-peer computing enablesthree novel aspects that are not appropriately supported by the WorldWide Web:

[0011] Frictionless publication of content: In a peer-to-peer system,every peer machine is both a consumer and a publisher of information.Publishing information in such a system can be as easy as creating a newfile.

[0012] Low barrier to revision and synchronization: Published files canbe edited and updated by their author or any person having writepermission on the file, either on the local machine or remotely.Synchronization is achieved transparently by the peer-to-peerinfrastructure by keeping track of the current version of the publishedresources, and of which peer machines are caching the correct version.

[0013] Active role of peer machines: While on the World Wide Web usermachines are mainly passive participants, in a peer-to-peer environmentthose machines can become an active part of distributed applicationsthat span many peers. For instance, in a distributed game application,every participant machine runs a copy of the game software.

[0014] One of the most promising benefits of the peer-to-peer model isthe ability to seamlessly “cache” resources on multiple machines, bothto provide robustness against one particular source of content goingoff-line, and to maximize the download performance by transparentlyselecting the fastest and closest possible source(s) of a download.

[0015] However, this model poses a series of difficulties fordistributing restricted content. This is due to the multiplicity of peerproviders for any given content, and the fact that those peer providersare operated by users and thus escape the direct control of a centraltrusted administration authority. The traditional approach to accesscontrol, based on centralized authorities (such as directory servers),would lose most of the efficiency benefits provided by the peer-to-peermodel.

[0016] The main challenges of the peer-to-peer model with respect toaccess control include the following issues:

[0017] Distributed operation: In large peer-to-peer systems, it isnecessary that most of the effort be performed by the providers andconsumers of information, thereby involving centralized servers aslittle as possible. An access control infrastructure for a peer-to-peernetwork must be mostly distributed, while at the same time being bothsecure and efficient.

[0018] Compatibility with caching: As one of the main benefits of thepeer-to-peer model is the ability to replicate resources to distributethe load, it is necessary that the access control infrastructureintegrate seamlessly with the content replication and caching.

[0019] High volume scalability: To accommodate extensible networks withpotentially hundreds of millions of users, it is necessary that theaccess control mechanism be highly scalable.

[0020] Traditional approaches to distributed or semi-centralized accesscontrol are based on an “authentication-based” model, in which users areauthenticated, and access lists are checked, before access requests maybe granted. The authentication schemes vary, but are usually based oneither of:

[0021] The Kerberos model, in which trusted servers vouch for theauthenticity of a consumer to a producer.

[0022] The Public Key Infrastructure (PKI) model, in which peers areauthenticated using a hierarchy of certificates rooted in a trustedauthority.

[0023] Unfortunately, authentication quickly becomes impractical andinefficient when the size of the network grows. It also raises concernswhen used with a large-scale caching mechanism, as it behooves to allthe cachers of a resource to enforce the same access rights as specifiedby its original publisher. This approach has a number of other problems,which are recapitulated below:

[0024] All cachers need to be trusted that they correctly enforceauthentication and access control policies. A single compromised cachercan damage the security of the entire system.

[0025] Cachers will need to maintain up-to-date access lists for allcached resources, and enforce a strict policy of checking credentialsbefore granting any content.

[0026] Cachers can only cache resources which they are themselvesgranted access to.

[0027] The burden of enforcing access properties lies with the publisherand all cachers of a resource, as opposed to the recipient.

[0028] It is difficult to verify the legitimacy of a user's request,when such legitimacy derives from the user's membership to a group (orchain of groups).

[0029] There is a feeling of inadequacy to have a large number ofcachers maintain clear-text copies of restricted material.

[0030] Finally, it is necessary to establish a secure communicationchannel between requestor and cacher, for every download request. Thiscould be achieved either via a Kerberos-like protocol (which wouldrequire extra communications to a heavy duty central ticket server), oran SSL-like protocol between clients (which is computationally expensiveand incurs a large set-up time). Either approach would cause undesirableoverhead in the communication process.

BRIEF DESCRIPTION OF DRAWINGS

[0031] The present invention will be described by way of exemplaryembodiments, but not limitations, illustrated in the accompanyingdrawings in which like references denote similar elements, and in which:

[0032]FIG. 1 illustrates an overview of the present invention, inaccordance with one embodiment;

[0033]FIG. 2 illustrates the logical relationship between a publishedresource, its resource key, access control list and resource key file ofa publisher peer system, and client key files of consumer peer systemsof FIG. 1 in further detail in accordance with one embodiment;

[0034]FIG. 3 illustrates the registration operation flow for a potentialconsumer peer system under the present invention, in accordance with oneembodiment;

[0035]FIG. 4 illustrates the initialization operation flow of apotential consumer peer system for publishing its encryption public keyfor use by resource publishers to authorize the peer system access toselected ones of their published resources under the present invention,in accordance with one embodiment;

[0036]FIG. 5 illustrates the resource publication operation flow of apublisher peer system for generating and publishing a resource key filefor a resource to be published with distributed access control under thepresent invention, in accordance with one embodiment;

[0037]FIG. 6 illustrates the resource access operation flow of aconsumer peer system for accessing published resources with distributedaccess control under the present invention, in accordance with oneembodiment;

[0038]FIG. 7a illustrates an example directory structure having extendedinheritable distributed access control of the present invention, inaccordance with one embodiment;

[0039]FIG. 7b illustrates the operational flow for recovering a resourcepublished in an obfuscated manner where inheritable distributed accesscontrol is also supported, in accordance with one embodiment;

[0040]FIG. 8 illustrates another embodiment of the present invention,wherein access of the published resources may be authorized to groups,where the ultimate potential consumer peer systems are members of theauthorized groups;

[0041]FIG. 9 illustrates the concept of groups, group membership files,and group key files of the present invention, in accordance with oneembodiment;

[0042]FIGS. 10a-10 b illustrate the operational flow for recovering agroup encryption private key by a consumer peer system under the presentinvention, in accordance with one embodiment;

[0043]FIG. 11 illustrates the employment of gateway to facilitate an“outside” peer system in securely accessing a collection of “internally”published resources;

[0044]FIG. 12 illustrates the operational flow for writing or executinga published resource under the distributed cryptographic based accesscontrol of the present invention;

[0045]FIGS. 13a-13 b illustrate the operational flow for filteringsearch results based on the access permissions of the users requestingthe search, in accordance with two embodiments; and

[0046]FIG. 14 illustrates an example computer system suitable for use aspeer system to practice the present invention, in accordance with oneembodiment.

DETAILED DESCRIPTION OF THE INVENTION

[0047] The present invention includes a distributed, scalablecryptographic based methodology for controlling access to publishedresources by peer systems. In the description to follow, various aspectsof the present invention will be described. However, the presentinvention may be practiced with only some or all aspects of the presentinvention. For purposes of explanation, specific numbers, materials andconfigurations are set forth in order to provide a thoroughunderstanding of the present invention. However, the present inventionmay be practiced without some of the specific details. In otherinstances, well known features are omitted or simplified in order not toobscure the present invention.

[0048] Parts of the description will be presented in terms of operationsperformed by a processor based device, using terms such as resources,data files, executables, directory, sub-directory, publishing,accessing, determining and so forth, consistent with the manner commonlyemployed by those skilled in the art to convey the substance of theirwork to others skilled in the art. As well understood by those skilledin the art, the quantities take the form of electrical, magnetic, oroptical signals capable of being stored, transferred, combined, andotherwise manipulated through mechanical, electrical and/or opticalcomponents of the processor based device.

[0049] The term “resource” as used in the present application includesdirectories, sub-directories, non-executable data files of all types, aswell as executable binaries or dynamic entities such as Web services,whereas the term “processor” includes microprocessors,micro-controllers, digital signal processors, and the like, that arestandalone, adjunct or embedded.

[0050] Various operations will be described as multiple discrete stepsin turn, in a manner that is most helpful in understanding the presentinvention. However, the order of description should not be construed asto imply that these operations are necessarily order dependent. Inparticular, these operations need not be performed in the order ofpresentation.

[0051] Further, the description repeatedly uses the phrase “in oneembodiment”, which ordinarily does not refer to the same embodiment,although it may; and the terms “comprising”, “having”, “including”, andother terms of the like, as used in the claims as well as in thespecification are synonymous.

Overview

[0052] Referring now first to FIG. 1, wherein a block diagramillustrating an overview of the present invention, in accordance withone embodiment, is shown. As illustrated, for the embodiment, peersystems 102, with the assistance of registry and certification authorityservers 104 and resource naming and locator servers 106, publish andshare resources with one another. As alluded to earlier, thepublished/shared resources may include but are not limited todirectories, sub-directories, non-executable data types of all forms,executable binaries, as well as dynamic entities such as Web services.

[0053] In accordance with the present invention, peer systems 102 areeach incorporated with cryptographic access control (CAC) client 110 ofthe present invention to facilitate publication of resources, and accessto the published resources, with access control. CAC clients 110 areincorporated with the teachings of the present invention, enablingpublication and consumption of resources with access control to beeffected more efficiently and the responsibilities borne more fairly, ina distributed and scalable manner, by all peer systems. As will bedescribed in more detail below, the distributed manner of effectingaccess control to the published resources, for the embodiment, employsencryption public keys of the individual peer systems, or groups of peersystems, to be authorized to access the published resources.

[0054] For the illustrated embodiment, in addition to facilitatingpublication of resources and access of the published resources withdistributed access control, CAC client 110 also facilitates registrationof peer systems 102 with registry and certification authority 104, aswell as generation and publication of encryption public keys of peersystems 102. In particular, for the embodiment, the set of CAC clientfunctions 130 of client 110 are correspondingly provided through theresource publishing and access function 136, the registration function132, and the client key generation and publication function 134,respectively. Together, these functions enable peer systems 102 toeffect the desired distributed, scalable cryptographic based control foraccessing published resources.

[0055] Except for the teachings of the present invention, peer systems102, registry and certification authority servers 104 and resourcelocator servers 106 represent a broad range of these elements known inthe art. Further, while for ease of understanding, the present inventionis being described with peer systems 102, registry and certificationauthority servers 104 and resource locator servers 106 as separateentities, as those skilled in the art will appreciate, these are merelogical divisions; a system may assume the role of a publisher peersystem 102 at one point in time, and that of a consumer peer system 102or registry/certification authority server 104 or resource locatorserver 106 at another point in time. Moreover, the present invention maybe practiced with or without employing third party registry and/orcertification authority servers.

Basic Resource Publishing and Sharing Without Access Control

[0056] Continuing to refer to FIG. 1, the basic manner in which peersystems 102 publish and share resources 114 without access control willfirst be described. In this Figure, as well as in all subsequentFigures, published resources are depicted as bold boxes. Note that thepresent invention does not preclude peer systems 102, while practicingthe present invention, from nevertheless electing to publish and shareresources without access control for selected ones of the publishedresources, presumably resources of lesser importance in term of contentvalue, or resources intended for distribution to a broad audience.

[0057] The basic manner of resource publication and consumption withoutaccess control may be illustrated by the example scenario of a userAlice of a first peer system 102 wishing to share a resource with Boband Charlie of a second and a third peer system 102 respectively.Assuming all three peer systems 102 are properly installed with resourcepublication and access functions (such as CAC client 110), andregistered with appropriate resource naming and locator servers 106, thebasic resource publication/access process without access control, forthe embodiment, works as follows:

[0058] 1. Alice of first peer system 102 uses her CAC client 110 (morespecifically, resource publication & access (RPA) function 136) to causethe publication of the resource. Her CAC client 110 (RPA function 136)transmits the name and version of the resource to the assigned resourcenaming and locator server 106. In a preferred embodiment, resource namestake the form of Universal Resource Locators (URLs), although othernaming schemes could be used in alternate embodiments.

[0059] 2. When Bob of second peer system 102 tries to access theresource, Bob's CAC client 110 (RPA function 136) intercepts the requestand queries the assigned resource naming and locator server 106 for theresource, which responds by providing the address of Alice's peer system102. Bob's CAC client 110 (RPA function 136) then connects to Alice'sCAC client 110, and retrieves the resource from Alice's peer system 102,in a peer-to-peer fashion. Assuming that this is a static resource (suchas a document stored in a file), Bob's CAC client 110 (RPA function 136)also caches a copy of the resource on Bob's peer system 102.

[0060] 3. Upon successful receipt of the resource, Bob's CAC client 110(RPA function 136) notifies the resource naming and locator server 106that it now has a cached copy of the resource, and is ready to serve it.

[0061] 4. Subsequently, when Charlie of third peer system 102 tries toaccess the resource, the resource naming and locator 106 returns theaddress of Alice's peer system 102 (the original publisher), as well asthe address of Bob's peer system 102 (who now is a cacher). Charlie'sCAC client 110 (RPA function 136) may obtain the resource from eitherAlice or Bob's peer systems 102. However, if Alice's peer system 102 hadgone off-line in the meantime, the resource would still be availablefrom Bob's peer system 102—in which case only Bob's address would bereturned by the resource naming and locator service 106.

[0062] 5. If at a further later point in time, Alice revises theresource, her CAC client 110 (RPA function 136) will inform the resourcenaming and locator service 106 that a new version is available,resulting in the invalidation of all existing cached copies. In apreferred embodiment, this invalidation is achieved by having resourcenaming and locator service 106 purge all of its records about invalidcached copies; in the example above, resource naming and locator service106 would purge its records about Bob and Charlie's copies.

[0063] 6. At another later point in time, if Bob tries to access theresource, the resource naming and Jocator service 106 will now directthe request to Alice's peer system 102, disregarding Bob's own cachedcopy as obsolete.

[0064] The above scenario illustrates the basic principle of resourcepublication, caching and sharing—as provided by the underlying sharinginfrastructure without access control—over which the distributed accesscontrol invention herein described may be practiced. The protocol forresource publication, caching and. sharing with distributed accesscontrol is described in more detail in turn in subsequent sections.

Resource Keys, Access Control Lists, Resource Key Files and Client KeyFiles

[0065] Referring now also to FIG. 2 (in addition to FIG. 1), variouselements of the distributed access control of the present invention, inaccordance with one embodiment, will be described. The present inventioncontemplates that a published resource, such as resource 114 a, will bedistributed in an encrypted form. For the embodiment, distributed copiesof published resources 114 are encrypted by corresponding resource keys120 generated by resource key generation and publication function 134.In various embodiments, resource keys 120 generated are symmetric keys,such as symmetric keys of random bit strings of a given length, designedfor use by symmetric ciphers. Examples of symmetric ciphers include butare not limited to the Rijndael (a.k.a. AES) or triple-DES algorithmswell-known to those skilled in the art.

[0066] Resource keys 120 are published or made available by resource keygeneration and publication function 134 only through correspondingresource key files 116 of the published resources. Effective access topublished resources 114 is restricted to authorized peer systems 102, byeffectively restricting accesses to resource keys 120 required todecrypt and recover published resources 114. Specifically, for theembodiment, accesses to resource keys 120 are effectively restricted toauthorized peer systems 102 by only including resource keys 120 inresource key files 116 in an encrypted form. More specifically, multipleencrypted entries of a resource key 120 for a published/distributedresource 114 are generated and included in the corresponding resourcekey file 116 of the published resource, with each entry of resource key120 encrypted using the encryption public key (Grantee K_(pu)) 113 ofthe authorized peer system 102. As a result, only authorized peersystems 102 are able to recover resource keys 120, and in turn recoverthe content of the published resources 114.

[0067] In various embodiments, client key generation and publishingfunction 134 signs the resource key files 116, to facilitate theirauthentication by authorized peer systems 102. The resource key files116 may be signed using any one of a number of signature techniquesknown in the art.

[0068] For the embodiment, the encryption public keys Grantee K_(pu) 113of potential consumer peer systems 102 are published or made availableby resource key generation and publishing function 134 to all publisherpeer systems 102 through client key files (CKF) 112, published in theconventional manner, i.e. without any access control.

[0069] As will be described in more detail below, in one embodiment, theencryption public key 113 published in a client key file 112 may be anencryption public key of a group to which the ultimate grantee orauthorized peer systems 102 are members. However, for ease of theunderstanding, the present invention will first be described with theauthorization or access grant being directly given to individual peersystems 102. The “group” aspect of the present invention will bedescribed in more detail later.

[0070] Further, as will be also described in more detail below, resourcekey file 116 may also include other entries in support of other advancedfeatures of the present invention, e.g. an encrypted entry of thecorresponding resource's signature.

Registration and Initialization of Potential Consumer Peer Systems

[0071] FIGS. 3-4 illustrate the operational flow of the presentinvention for registering and initializing a potential consumer peersystem 102 to practice the present invention, in accordance with oneembodiment. As illustrated in FIG. 4, a peer system 102 interested inbeing able to be granted access to resources published in accordancewith the present invention, first generates or selects a pair ofencryption public and private keys (K_(pu) 113 and K_(pr) 115,respectively), using e.g. client key generation and publication function134, block 402. Thereafter, for the embodiment, the peer system 102(more specifically, registration function 132) contacts a participatingregistry and certification authority server, e.g. server 104 b, bysending message 302 in FIG. 3. The peer system 102 (more specifically,registration function 132) registers itself and requests thecertification authority to certify, or cryptographically sign, itsencryption public key K_(pu) 113, block 404. For the embodiment, inresponse, the certification authority 104 b cryptographically signs theencryption public key K_(pu) 113 of the registering peer system 102, andreturns the signed encryption public key 113 to the registering peersystem 102 in message 304 of FIG. 3. In turn, the peer system 102 (morespecifically, client key generation and publication function 134) placesthe cryptographically signed encryption public key K_(pu) 113 in aclient key file (CKF) 112, and (via resource publishing and accessfunction 136) publishes the client key file 112 for use by publishers ofresources, block 406. Publication of a client key file 112 for theembodiment, as described earlier, is accomplished in a conventionalmanner without access control, i.e. by notifying an assigned resourcenaming and locator server 106 of the name and version of the client keyfile 112.

[0072] In a preferred embodiment, the present invention may be practicedwith peer system 102 (more specifically, client key generation andpublication function 134) signing and/or certifying its own encryptionpublic key K_(pu) 113 instead. For the embodiment, the peer system 102(more specifically, client key generation and publication function 134)generates both a signing key pair (S_(pu) 117 and S_(pr) 119,respectively) and an encryption key pair (K_(pu) 113 and K_(pr) 115,respectively). For this embodiment, the certification authority 104certifies the signing public key S_(pu) 117 of the peer system 102instead of the encryption public key K_(pu) 113; peer system 102 thenuses the corresponding signing private key S_(pr) 119 to generate acertificate for its encryption public key K_(pu) 113, without contactingthe certificate authority 104. Both certificates are published in theclear, as previously described, in one or several files jointly referredto as the client key file 112. For the present embodiment, the validityof the encryption public key 113 is defined as the conjoint validity ofboth certificates (for keys 113 and 117, respectively), and verifiedaccordingly per the certification verification process to be describedlater. Said method of self-certification of an encryption public key 113by authority of a certified signing key pair S_(pu) 117 and S_(pr) 119is used, in one embodiment, by peer system 102 to renew its encryptionkey pair K_(pu) 113 and K_(pr) 115, respectively, without having torequest a new certificate from the certification authority.

[0073] In one embodiment, encryption private keys K_(pu) 113 and K_(pr)115 are randomly generated. In another embodiment, the series ofencryption private keys K_(pu) 113 and K_(pr) 115 used by peer system102 are deterministically generated from a random seed, such as, in oneembodiment, per the process described later when generation of theencryption private key for a group under a preferred embodiment isdescribed. In one embodiment, the random seed is securely provided tothe registry and certification authority server 104 or other trustedauthority during initial registration, for the purpose of keeping allpast, present and future encryption private keys K_(pu) 113 and K_(pr)115 of peer system 102 in escrow, or, in a roaming solution, forallowing a user to reconstruct his current encryption private key K_(pr)115 from a remote location.

Publication of Resources and Resource Key Files

[0074] Publication by peer systems 102 of a resource 114 to becontrolled via the distributed access control of the present inventionincludes the companion publication of the associated resource key file(RKF) 116, to provide the authorized peer systems 102 with the necessaryresource key 120 to recover the published resource 114. In accordancewith the present invention, when requested, a published resource 114, ismade available to the requesting peer system 102 in an encrypted form;more specifically, the published resource 114 is encrypted using itsresource key 120. Publication of the corresponding RKF 116 in and ofitself is accomplished in a conventional manner (i.e. without accesscontrol); in one embodiment, this is accomplished by notifying anassigned resource naming and locator server 106.

[0075]FIG. 5 illustrates the operational flow of the relevant aspects ofCAC client 110 (more specifically, client key generation and publication(CKGP) function 134) for generating and publishing a RKF 116 for aresource 114 to be published with distributed access control, inaccordance with one embodiment. As illustrated in block 502, CAC client110 (CKGP function 134) first receives the list of identifications ofpeer systems 102 to be granted access to the resource 114 to bepublished. This list can be made available by a user of the publisherpeer system 102 through a conventional user interface, or by supplyingCAC client 110 with a comma separated value (CSV) or XML-encoded fileenumerating the “grantees”.

[0076] Next, in block 504, CAC client 110 (CKGP function 134) generatesan access control list (ACL) 118 for the resource 114 to be publishedwith distributed access control, enumerating the grantees, i.e. peersystems 102 to be granted access to the resource 114 to be publishedwith distributed access control.

[0077] Next, for the embodiment, in block 506, CAC client 110 (CKGPfunction 134) generates a resource key 120 to be used to encrypt theresource for distribution. In one embodiment, the resource key 120 israndomly generated, intended for use in conjunction with a symmetriccipher. An example of a symmetric cipher is the Rijndael (a.k.a. AES)cipher known in the art.

[0078] Next, in block 508, upon generating resource key 120 for theresource 114 to be published with distributed access control, CAC client110 (CKGP function 134) initializes an empty RKF 116 for the resource tobe published with distributed access control. Then, in blocks 510-516,CAC client 110 (CKGP function 134) iteratively creates the contents ofthe RKF 116 for the resource to be published with distributed accesscontrol.

[0079] For the embodiment, in block 510, for each grantee 102 in the ACL118, CAC client 110 (CKGP function 134) accesses and retrieves from thegrantee's published client key file 112, the grantee's certificate forthe grantee's encryption public key Grantee K_(pu) 113, verifies thecertificate in a conventional manner known in the art, and extractsencryption public key Grantee K_(pu) 113. In block 512, upon successfulauthentication and extraction of the encryption public key GranteeK_(pu) 113, CAC client 110 (CKGP function 134) generates an encryptedentry of the resource key 120, encrypting the resource key 120 using theretrieved Grantee K_(pu) 113 of the grantee 102. In block 514, upongeneration of the encrypted resource key, CAC client 110 (CKGP function134) places the generated entry in the RKF 116.

[0080] Operations 510-514 are repeated for each grantee, until it iseventually determined, at block 516, that an encrypted entry of theresource key 120 of the resource has been generated and placed into RKF116 for each peer system 102 to be granted access to the resource to bepublished.

[0081] Thereafter, in block 518, for the embodiment, CAC client 110(CKGP function 134) signs and publishes the RKF 116. RKF 116 may besigned employing any signature technique known in the art. As describedearlier, publication of the RKF 116 is accomplished in a conventionalmanner without access control, i.e. by notifying its name and version toan appropriate resource naming and locator server 106.

[0082] In one embodiment, a publishing peer system 102 of a resource 114whose access is to be controlled via the distributed access control ofthe present invention will locally store the published resource 114 inplaintext form on publisher 102. That is, encryption of the publishedresource 114 is performed only when a copy of the resource is providedto a requesting peer system 102 in response to its request. In alternateembodiments, of course, a publisher peer system 102 may locally maintaina published resource 114 in encrypted form, i.e. by pre-encrypting allpublished resources.

[0083] Note that in the preferred embodiment of the present invention,no check is preformed on a requestor for a resource as to whether therequestor is an authorized peer system 102. Denial of access to thecontents of published resource 114, in the event the requesting peersystem 102 is not an authorized peer system, relies on the fact that anunauthorized peer system will not be able to recover the requiredresource key 120 necessary to recover the content of the resource 114 ofinterest, and therefore will not be able to recover and access thecontent of the resource 114.

[0084] In preferred embodiments, a directory or sub-directory resourceis published in the form of a regular file, called a Directory Listing,containing the meta-data describing the content of the directory orsub-directory. Directory Listings are published using the samepublication, encryption, and access control mechanisms as otherresources.

Accessing Published Resources with Access Control

[0085]FIG. 6 illustrates the operational flow of the relevant aspects ofCAC client 110 for accessing a published resource 114 with distributedaccess control, in accordance with one embodiment of the presentinvention. As illustrated, for the embodiment, upon instructed tofacilitate retrieval of a published resource 114, more specifically,having been informed by a resource naming and locator server 106 of thelocation of a resource of interest 114 and the location of thecorresponding resource key file (RKF) 116, CAC client 110 (morespecifically, resource publishing and access (RPA) function 136) firstfetches the RKF 116 of the resource 114 of interest from the originalpublisher of the resource or one of its cachers, block 602.

[0086] Then, in block 604, CAC client 110 (RPA function 136) locates itsentry of the encrypted resource key (RK) 120 in the retrieved RKF 116.In one embodiment, the intended beneficiary, i.e. the identity of theintended grantee, of each encrypted resource key entry in RKF 116 isidentified with the name of the intended beneficiary peer system 102. Inalternate embodiments, the encrypted resource key entries in RKF 116 arenot identified, and the intended beneficiary or grantee may bedetermined on a trial and error basis.

[0087] For the embodiment, in block 606, CAC client 110 (RPA function136), using its corresponding encryption private key K_(pr) 115,proceeds to decrypt its entry to recover the resource key RK 120.

[0088] Continuing to refer to FIG. 6, upon recovering the resource key120, CAC client 110 (RPA function 136) then proceeds, in block 608, toretrieve a copy of the resource of interest 114, in encrypted form, fromits original publisher or one of its cachers. Upon obtaining theresource of interest 114 in an encrypted form, CAC client 110 (RPAfunction 136) proceeds, in block 610, to recover its content bydecrypting the encrypted copy using the recovered resource key 120.

[0089] For the embodiment, assuming the consumer peer system 102 isinterested in becoming a cacher of the resource of interest 114, CACclient 110 (RPA function 136) causes a copy of the resource 114 inencrypted form and the corresponding RKF 116 to be cached locally. Asdescribed earlier for conventional publication of resources, in likemanner, CAC client 110 (RPA function 136) notifies an assigned resourcenaming and locator server 106 of the existence of the cached copies ofthe encrypted resource 114 and the RKF 116.

[0090] In one embodiment, unlike the original publisher of the resourceof interest, the resource is cached by the cacher grantee peer system102 in the encrypted form.

Advanced Features

[0091] Having described the basic features of the present invention, wenow turn to describe the advanced features of the present invention inturn, including but not limited to the features of group grantees,password protected publications, obfuscated publications, resource keyfile inheritance, accesses via gateways, write or execute accesses,secured resource search, and so forth.

Group Grantees

[0092] As alluded to earlier, in various embodiments, authorizations maybe given to a group of which the ultimate peer systems 102 are members,as opposed to the individual peer systems 102 as described thus far.FIG. 8 illustrates one such embodiment. As shown, in addition to theearlier described elements, for embodiments including support forgranting authorizations to grantees through their affiliations ormembership in groups, peer systems 102 also include group membershipdatabase (GMDB) 122 and group key files (GKF) 124.

[0093]FIG. 9 illustrates group creation in further detail, including thecreation of group membership lists and group key files, in accordancewith one embodiment. As illustrated, to facilitate the group granteefeature of the present invention, for a group 900, a group administrator902, which may be any one of a publisher or consumer peer system 102, ora dedicated peer system 102 acting as the group administrator, keepstrack of the Group Member Master List 904 that includes all Members 906of the group 900, where a member 906 may be an individual peer system102 or another group 900. The group administrator 902 first generates anencryption public and private group key pair for the group 900, GroupK_(pu) 912 and Group K_(pr) 914, respectively. The group administrator902 next creates a group key file (GKF) 124 that includes entries of thegroup's encryption private key Group K_(pr) 914, correspondinglyencrypted for every member 906 of the group 900. The encryption groupprivate key Group K_(pr) 914 is encrypted using the correspondingencryption public keys Grantee K_(pu) 113 of the group members 906(which may e.g. be retrieved from the members' published client keyfiles 112). Group administrator 902 also publishes its own encryptionpublic key Group K_(pu) 912 in a CKF 112 for use by publisher peersystems 102 similar to the way other potential consumer peer systems 102publish their encryption public keys 113 in client key files 112.

[0094] Note that as illustrated, members 906 of a group 900 maythemselves be individual peer systems 102 or groups 900. No restrictionis placed on group nesting; in particular, groups may circularly includeeach other without adversely affecting the system. In particular, agroup 900 may also have only one member 906, or multiplepersonifications of one member, both referred as a “singleton” group.The latter application of “singleton” group is particularly useful instreamlining access granting to a user, while allowing the user to havea continually changing portfolio of peer systems 102.

Determining Authorization for Group Grantees

[0095]FIGS. 10a-10 b illustrate the operational flow of the relevantaspects of CAC client 110 (more specifically, RPA function 136) foraccessing a published resource 114 in an embodiment supporting grantingresource access authorization through membership in groups. Theoperation is set to determine a path of group membership andcorresponding group private keys from the CAC client 110 to at least onegroup accessor listed in the retrieved RKF 116 for resource 114. For theembodiment, the operation implements a “breadth first search” procedureas known in the art, augmented with a local database of visited groupmemberships, the Group Membership Database (GMDB) 122, maintained by theCAC client 110 for caching and loop breaking purposes.

[0096] As illustrated, for the embodiment, when processing a RKF 116,block 1002, CAC client 110 (RPA function 136) first checks to see ifsaid RKF 116 contains an entry for this peer system 102, block 1004. Ifsuch an entry is found, the resource key (RK) 118 for the resource isretrieved from the RKF 116, block 1006, as previously described under“Accessing Published Resources with Access Control”, and the publishedresource 114 can be decrypted using the RK 118, block 1008.

[0097] If the RKF 116 does not contain an entry for CAC client 110, theCAC client 110 (RPA function 136) performs an exploration of the groupstructure with the goal of finding a group of which it is a member andwhich is either listed in RKF 116 or for which a chain of groups existssuch that by following the chain one can find a group listed in RKF 116.In a preferred embodiment, this exploration is performed using abreadth-first approach well known to those skilled in the art.

[0098] The CAC client 110 (RPA function 136) starts by initializingOpenGroups, the list of all groups that have not yet been explored, tothe list of groups listed in RKF 116, block 1010. The CAC client 110(RPA function 136) then repeats the following actions 1012-1028, untileither a chain of groups is found, or OpenGroups becomes empty, blocks1012 and 1014. In the latter case, the CAC client 110 (RPA function 136)concludes, in block 1014, that it has not been granted access topublished resource 114.

[0099] In block 1016, the next group on OpenGroups is selected forexploration and removed from OpenGroups. At block 1018, CAC client 110(RPA function 136) tests whether an up-to-date entry for this groupalready exists in its GMDB 122. If such an entry is found, execution ofthe algorithm proceeds at block 1020, where the client checks whetherthe entry in GMDB 122 also contains the group private key Group K_(pr)914. If the group private key 914 is not found in the GMDB 122,execution continues back at block 1012.

[0100] If the group private key Group K_(pr) 914 is found in GMDB 122 atblock 1020, execution of the algorithm continues at block 1030, wherethe information in the GMDB 122 is used to follow a chain of groupsleading to a group listed in the RKF 116 of published resource 114; foreach element in the chain, the group private key 914 of the previouselement (i.e. group) in the chain is used to recover the group privatekey 914 of the current element (i.e. group) in the chain, ultimatelyleading to the retrieval of the resource key 120 and enabling thedecryption of the published resource 114, block 1032, as in the earlierdescribed operation of 606 of FIG. 6. As the group private keys 914 areuncovered in the process described above, the GMDB 122 is also updatedto cache these group private keys 914 for future executions of thealgorithm in FIGS. 10a-10 b.

[0101] Back at block 1018, if no valid entry is found in the GMDB 122,the GKF 124 for this group is fetched by CAC client 110 (RPA function136), block 1022. Next, at block 1024, the group information is added asa new entry to the GMDB 122. In one embodiment, the new GMDB entry isformulated by combining the following information: the group name; achecksum or hash of the fetched GKF 124; the timestamp of the GKF 124;the group private key 914, which is left empty at this point.

[0102] At block 1026, the fetched GKF 124 is examined to determinewhether it contains an entry for CAC client 110. If such an entry isfound, execution continues at block 1030, and the published resource 114can be accessed.

[0103] If at block 1026, no entry for CAC client 110 is found in theretrieved GKF 124, all the groups in GKF 124 are added to OpenGroups forfurther exploration, block 1028, and execution continues back at block1012.

[0104] Accordingly, authorization may also be indirectly granted to peersystems 102 by authorizing groups to which the ultimate beneficiary peersystems 102 are members.

Efficient Updating of Resource Keys and Group Key Pairs

[0105] In one embodiment, resource keys 120 and group key pairs 912 and914 are randomly generated, upon the original publication of a resource114 or group 900, and every time the access control list 118 for theresource 114, or the group member master list 904 for group 900, change,respectively. However, in a preferred embodiment, these keys aregenerated using the deterministic process described below. This keychaining approach allows CAC clients 110 (more specifically, client keygeneration and publishing function 134) to advantageously use thecaching of resources on peer systems 102, without having to re-publish aresource 114 each time its resource key 120 changes, and without havingto re-publish a group key file 124 each time the group key pair 912 and914 of one of its grantee groups 900 changes.

[0106] In the preferred key chaining approach, resource keys 120 aregenerated in a deterministic manner from a random “seed” associated withthe RKF 116 and kept secret by the publishing peer system 102, in such away that old keys may be easily derived from newer ones, but not theother way around. An example of such approach to generating the resourcekey is described below, when generation of the encryption private keyfor a group under a preferred embodiment is described; said generationmethod as described applies to the generation of private keys of anasymmetric cipher, but may also be practiced for generating the keys ofa symmetric cipher. In a preferred embodiment, this approach is used inconjunction with frequent scheduled renewal of resource keys 120 aspublished in RKFs 116, combined with. asynchronous re-encryption ofresources.

[0107] In the preferred key chaining embodiment, the public/private keypair 912 and 914 of a group 900 is constructed in a deterministic manner(as opposed to being generated randomly). More specifically, a scheme isused wherein knowledge of the current group private key Group K_(pr) 914allows easy derivation of all previous group private keys 914 for thegroup 900. The scheme advantageously allows the keys to be changedfrequently (e.g. to effect group membership revocation), withoutrequiring either the group 900 or its member clients 906 to store any ofthe old keys.

[0108] More specifically, in one embodiment, group administrator 902generates its keys in the following deterministic manner:

[0109] a) Group administrator 902 first generates and saves a secretrandom “seed”, along with an index number N. The initial value of theindex N is configurable, but is typically chosen to be a large number,such as one million, to allow for a long period of operation accordingto the manner described herein. The index N is then decreased by oneevery time a new encryption key pair Group K_(pu) 912 and Group K_(pr)914 is generated for the group 900 under this scheme.

[0110] b) Group administrator 902 then repetitively applies a one-wayfunction to the seed N times, for the current value of N, to obtain theinitial group encryption private key Group K_(pr) 914. The one-wayfunction may be any one of such functions known in the art, e.g. MD5 orSHA-1.

[0111] c) Group administrator 902 then computes the corresponding groupencryption public key Group K_(pu) 912 in a conventional manner that iswell-known to those skilled in the art.

[0112] In a preferred embodiment that uses EIGamal as the underlyingpublic key cipher, the actual EIGamal private key is obtained from thegroup encryption private key Group K_(pr) 914 by hashing Group K_(pr)914 to produce a bit string of the desired number of bits; from there,the EIGamal public key is easily derived using the methods known tothose skilled in the art. In this embodiment, the group encryptionpublic key Group K_(pu) 912 is simply taken as the EIGamal public key.

[0113] d) Certification is then obtained for the group encryption publickey Group K_(pu) 912, either by asking a registry and certificationauthority server 104 to sign Group K_(pu) 912, or by having the groupadministrator 902 signing and/or certifying its own encryption publickey Group K_(pu) 912, according to the method described earlier under“Registration and Initialization of Potential Consumer Peer Systems”.The certified group encryption public key Group K_(pu) 912 is published,along with the index N used to generate it, in a CKF 112 as earlierdescribed for an individual potential consumer peer system 102.

[0114] e) Next, an initial empty GKF 124 is also created and publishedby group administrator 902.

[0115] f) Thereafter, as peer systems 102 or groups 900 are individuallyadmitted or added as members 906 of the group 900, identification ofeach member peer system 102 or group 900 is added by the groupadministrator 902 to the group's master member list 904. Further, theCKF 112 of the member peer system 102 or group 900 is accessed, and itsencryption public key Grantee K_(pu) 113 is retrieved and verified. Uponverification, the current encryption private key of the group, GroupK_(pr) 914, is encrypted using the member's encryption public keyGrantee K_(pu) 113, and the encrypted entry is added to the GKF 124 ofthe group.

[0116] In one embodiment, the key publication portion of operation (f)is repeated periodically to ensure that the group's encryption privatekey Group K_(pr) 914 is published with the latest, i.e. most currentencryption public key Grantee K_(pu) 113 of its members, should thelatter change. In alternate embodiments, group administrator 902 mayalso subscribe, e.g. with a resource locator server 106, to be notifiedof any re-publication of the CKFs 112 of its member peer systems 102 orgroups 900, and repeat its private key publication operation for amember 906 only upon having been notified of changes to the member'sencryption public key Grantee K_(pu) 113.

[0117] In one embodiment, when a member 906 is removed from the group900, group administrator 902 decrements N by one, and a new groupencryption private key Group K_(pr) 914 is generated as earlierdescribed, i.e. with the known one way function applied to the savedseed N times. The corresponding group encryption public key Group K_(pu)912 is re-computed, re-certified, and re-published. Then, the new groupencryption private key Group K_(pr) 914 is “re-published” for theremaining members 906, i.e. the corresponding entries in the group's.GKF 124 are replaced with new encrypted entries of the group's newencryption private key Group K_(pr) 914 generated as earlier described.

[0118] The group encryption key computation scheme above ensures that agroup member 906, having access to a GKF 124 containing the most recentgroup encryption private key Group K_(pr) 914, can use it to derive anyolder group encryption private keys Group K_(pr) 914, as may be neededto decrypt RKF entries previously published with those keys. Inparticular, this technique saves the CAC client 110 from regeneratingand republishing RKFs 116 every time a group client listed as grantee tothe resource 114 and for which there is an entry in the RKF 116 changesand republishes its encryption public key. The resulting savings arevery significant, as the number of RKFs in the system can be potentiallyvery large.

[0119] In one embodiment, step (b) above, comprising the repeatedapplication of a one-way function N times and the correspondingderivation of the encryption private key Group K_(pr) 914, are replacedby the following more efficient method. This method assumes that theinitial value of N chosen in step (a) is the product of a number m ofconstant factors B₁, . . . , B_(m). For simplicity, the foregoingexposition assumes that m=2; the method is easily generalized for anynumber m:

[0120] (b1) Group administrator 902 determines the two unique numbersN₁, N₂, such that N=N₁*B₁+N₂.

[0121] (b2) Group administrator 902 repetitively applies a one-wayfunction F₁ to the seed value (N₁+1) times. The result is denoted K₁.

[0122] (b3) Group administrator 902 repetitively applies one-wayfunction F₁ to the seed value N₁ times, then a different one-wayfunction F₂ to the result N₂ times. The result is denoted K₂.

[0123] (b4) The group encryption private key Group K_(pr) 914, to be“published” in the GKF 124, is then defined as the pair K₁ and K₂. (Inone embodiment that uses EIGamal as the underlying public key cipher,the actual EIGamal private key is obtained by hashing the concatenationof K₁ and K₂ to produce a bit string of the desired number of bits, inaccordance with the methods practiced in the art; from there, the publickey Group K_(pu) 912 is obtained as previously described.)

[0124] Referring to the above embodiment, those skilled in the art willappreciate that any group encryption private key Group K_(pr) 914 ofindex N′ can easily be derived from the private key Group K_(pr) 914 ofindex N, by repeated applications of F₁ and/or F₂ to K₁ and/or K₂.,provided that N≦N′.

WebGate Access

[0125] In various embodiments, support is provided to enable users of“outside” grantee peer systems, e.g. peer systems 102′ outside ofIntranet 1102 of FIG. 11, to access a collection of authorized“internally” published resources within the Intranet 1102. For a numberof these embodiments, the support is provided, through a gateway, e.g.WebGate 1106 of FIG. 11, separating the Intranet 1102 and the Internet1104, through which the “outside” peer systems 102′ access Intranet1102.

[0126] In one embodiment, the desired access is effectuated by havingthe resource key files 116 of the resources 114 to be accessible in thismanner, to include entries encrypting the resource keys 120 of theresources 114 using a master “WebGate” encryption public key, thusenabling WebGate 1106 to be able to recover the resource keys 120 of theresources 114 and decrypt each of the published resources 114 ofIntranet 1102 to be accessible in this manner for the “outside” peersystems 102′. In another embodiment, the ability for WebGate 1106 todecrypt each published resource 114 of Intranet 1102 to be accessible inthis manner for the “outside” peer systems 102′, is made possible byhaving the key pairs of the all peer systems 102′ stored in a user keydatabase (UKDB) 1110 accessible only to WebGate 1106.

[0127] For either embodiment, upon request by one such “outside” peersystem 102′, WebGate 1106 authenticates the requesting “outside” peersystem 102′; this may be accomplished using any one of a number of knownauthentication techniques. Upon authenticating the requesting “outside”peer system 102′, depending on the implementation, WebGate 1106 recoversthe resource key 120 for the resource of interest 114, using its own key(the earlier described “master” WebGate key) or retrieving therequesting peer system's key pair from the UKDB 1110, and retrieves theresource of interest 114 (provided in encrypted form). Thereafter,WebGate 1106 decrypts the retrieved encrypted resource of interest 114to recover the resource 114 for the requesting “outside” peer system102′, in a manner similar to the one described earlier under “AccessingPublished Resources with Access Control” and “Determining Authorizationfor Group Grantees”.

Write and Execute Accesses

[0128] In various embodiments, write and/or execute accesses ofpublished resources 114, in addition to read accesses, are alsosupported. As those skilled in the art will appreciate, write accessinvolves allowing a grantee peer system 102′ to edit a publishedresource of interest 114 which the grantee peer system 102′ isauthorized to edit, whereas execute access involves a publisher peersystem 102 executing a published resource of interest 114 (such as a Webservice invocation) at the request of a grantee peer system 102′. Oneembodiment of these two kinds of support, write access and executeaccess, is illustrated in FIG. 12.

[0129] In various embodiments, write access of a published resource 114is supported through the employment of the Hypertext Transfer Protocol(HTTP) or the Web-based Distributed Authoring and Versioning (WebDAV)protocol, designed for collaborative editing of web files. In alternateembodiments, other protocols/techniques may be employed instead.

[0130] For ease of understanding, the embodiment of will be describedwith the content owner or resource publisher peer system 102 beingreferred to as the Owner, and the grantee peer system 102′ with write orexecute access privilege being referred to as the Editor. The accessprivileges are granted by way of the RKFs 116 and the client keys113-115 as earlier described. Further, the embodiment assumes that theEditor's write request is proxied by the Editor's CAC client 110.

[0131] As illustrated in FIG. 12, an Editor 102′ first submits a requestdestined for an Owner 102, to edit or execute a published resource ofinterest 114, block 1202. The request is intercepted by the Editor's CACclient 110′, block 1204.

[0132] Upon interception, the Editor's CAC client 110′ retrieves theresource key file 116 of the published resource of interest 114 (asdescribed in “Basic Resource Publishing and Sharing without AccessControl”), and recovers the resource key 120 of the resource 114, block1206. Assuming success, the Editor's CAC client 110′ also contacts theOwner 102 to obtain a digital permit, also known as a “ticket”, whichfor the embodiment, is also encrypted by the Owner 102 using the sameresource key 120; the CAC client 110′ decrypts and recovers this“ticket” using the resource key 120, block 1208. Next, the Editor's CACclient 110′ sends the actual write or execute request to the Owner 102,including the retrieved “ticket”, block 1210.

[0133] Upon receipt, the Owner's CAC client 110 verifies theauthenticity and/or validity of the “ticket”, block 1212, and uponsuccessful verification, accepts the request, block 1214. Resultantly,thereafter, the Editor 102′ may write or execute the resource ofinterest 114 as desired, block 1216. For the embodiment, the request isrejected if the Owner's CAC client 110 is unsuccessful in verifying theauthenticity and/or validity of the “ticket”, block 1218.

Publishing with Passwords

[0134] In various embodiments, publishing of a resource 114 with accesscontrol based upon one or several passwords is also supported. Thepassword or passwords, similar to the grantees, may be provided to thepublisher peer system 102 through a user interface, or through a CSV orXML-encoded file enumerating the password/passwords.

[0135] For such embodiments, special entries, one per password, areadded to the RKF 116 when it is generated (i.e. prior to operation 518of FIG. 5). In one embodiment, each such entry will contain the resourcekey 120, encrypted one or several times using e.g. a symmetric cipher,with a salted hash of the password as key. In one embodiment, multipleencryptions are performed to increase the computing resources needed tobrute-force the password. As those skilled in the art will appreciate,the salt hash is used to thwart parallel dictionary attacks against allpasswords in the RKFs 116 or against many RKFs 116 at once. Further, thepassword protected entries are marked as such in the RKF 116 todifferentiate them from the non-password protected entries.

[0136] When accessing such a published resource (i.e. with distributedaccess control and password protection), CAC client 110 (morespecifically, resource publication and access (RPA) function 136), upondownloading the RKF 116, will attempt to find one non-password protectedentry in RKF 116 that it can decrypt, as earlier described. If CACclient 110 fails, and one or more password-protected entries arepresent, CAC client 110 (RPA function 136) may choose to prompt a userof the peer system 102 for the password; in an alternate embodiment, CACclient 110 (RPA function 136) may use other means (e.g. a permissionsconfiguration file) for obtaining the password. Upon having beenprovided with the password, CAC client 110 (RPA function 136) proceedsto attempt to decrypt all password-protected entries. If this attemptremains unsuccessful, the peer system 102 is not an authorized systemfor the published resource 114. If successful, CAC client 110 (RPAfunction 136) proceeds as earlier described to recover the resource key,and the content of the published resource 114 for consumption.

Obfuscated Publication

[0137] In the embodiments described thus far, a resource 114 is assumedto be published in its plain name, and served by a publishing or cachingpeer system 102 when said peer system is presented with a request forsaid plain resource name.

[0138] In alternate embodiments, for privacy reasons, a resource 114 maybe published using an obfuscated (or encrypted) name. In theseembodiments, the resource 114 will be served by a publishing or cachingpeer system 102 only upon presentation of a request containing theobfuscated name. Requests for the resource using the plain name aretreated specially by peer system 102, as will be described below,without giving any indication regarding the existence of an actualresource of that name.

[0139] In one embodiment, the obfuscated name for a resource 114 isderived based on the plain name, in a manner that is reversible only bythe publisher or owner of the resource. In one such embodiment, theobfuscated name for a resource 114 is obtained from the plain name ofthat same resource by encrypting the plain name using a symmetriccipher, using an obfuscation key generated and kept secret by thepublisher 102. The same obfuscation key is used for all obfuscationoperations by that publisher 102.

[0140] The obfuscated name is also encrypted using the resource key 120and included in RKF 116 (e.g. before operation 518 of FIG. 5). For agrantee, in addition to recovering the resource key 120, CAC client 110(RPA function 136) will also recover the obfuscated name of thepublished resource 114 as part of e.g. operation 606 of FIG. 6;operation 608 of FIG. 6 will be performed using this recoveredobfuscated name of the resource 114.

[0141] In one embodiment, where publication under an obfuscated name issupported, when the resource 114 is requested under its plain name, theoriginal publisher or a cacher peer system 102 returns the resource keyfile 116 instead. The practice thwarts accidental retrieval byunauthorized peer systems 102, or attacks by malicious systems makingrandom requests. This is especially useful when used in conjunction with“Inheritance of RKFs” as described below, to conceal the content ofentire directory trees to unauthorized peer systems.

[0142] In embodiments where obfuscated publication is supported, thepublished Directory Listing of a directory or sub-directory alsoprovides a correspondence between the clear text name of each resourcecontained in the directory, and the obfuscated name under which theresource is published.

Inheritance of RKFs

[0143] In various embodiments, as illustrated by FIG. 7a, inheritance ofan “ancestor” resource's RKF is also supported. That is, not everypublished resource 114 to be provided the distributed access control ofthe present invention has to have a directly associated RKF 116. Theresource key 120 recovered for an ancestor directory or sub-directoryresource (e.g. directory resource 702 in FIG. 7a) may be used to recoverthe descendant resources (e.g. resources 706 b), unless a descendantresource has a direct associated RKF 116 (e.g. sub-directory resource704 b) or a RKF 116 associated with an intervening ancestor resource(e.g. resources 706 a being subject to the RKF 116 associated with theancestor resource 704 b).

[0144] In embodiments where inheritance of RKFs is practiced, everypublished resource 114 to be accorded distributed access control inaccordance with the teachings of the present invention must have eithera directly associated RKF 116 or an ancestor directory or sub-directoryresource 114 that has a direct associated RKF 116.

[0145] For example, as illustrated in FIG. 7a, directory structure 700includes root directory 702, a number of sub-directories 704 a-704 c,and a number of leaf resources 706 a-706 b, such as non-executable datafiles and executable binaries. For the example, only exemplary rootdirectory 702 and sub-directory 704 b have directly associated RKFs 116.Thus, under the inheritance rules of these embodiments, accesses toresources 706 a and sub-directory 704 b are governed by RKF 116 directlyassociated with sub-directory 704 b. Whereas accesses to resources 706b, sub-directories 704 a and 704 c as well as root directory 702 aregoverned by RKF 116 directly associated with root directory 702.

[0146] Thus, for embodiments where inheritance of RKFs is practiced,when retrieving an RKF 116 of a resource of interest 114, a grantee peersystem 102 may necessarily traverse a directory structure, such asdirectory structure 700, upwards to locate the closest ancestor resource114 having a RKF 116, and retrieve the RKF 116 of this ancestorresource. The retrieved RKF 116 of the ancestor resource 114 is thenused for the (descendant) resource 114 of interest.

Inheritance of RKFs and Obfuscated Publication

[0147] In embodiments where inheritance of RKFs is supported inconjunction with obfuscated publication, after locating the closest RKF116 associated to one of its ancestor resources, retrieval of apublished resource 114 needs to additionally determine the obfuscatedname of resource 114 since, as described earlier, only a request forthis name will be honored by a publishing or caching peer system 102 ofthe resource.

[0148] Retrieval of a published resource 114 may be accomplished in thefollowing manner, illustrated in FIG. 7b:

[0149] a) Assuming that the clear text name of the resource of interest114 is R, let x₁, x₂, . . . , x_(n) be the path components in the namepath R.

[0150] b) Using the approach described previously, find the closest RKF116 associated with an ancestor resource of R. Let the clear text nameof this ancestor resource be S, and the path components in its name pathbe x₁, x₂, . . . , x_(s), where s n. Those skilled in the art willappreciate that the latter inequality holds by virtue of S being anancestor of R.

[0151] c) Let the constant L=n−s, the number of levels CAC client 110has to traverse “downwards” from S, the path of the enclosing RKF 116,to the path of R for the resource of interest 114; block 722.

[0152] d) Let variable U=S, the current obfuscated name of the resource.Let the index variable i=0; blocks 724 and 726.

[0153] e) If i L then stop, indicating success. The obfuscated name of Ris U; blocks 728-730.

[0154] f) If i<L, assert that U corresponds to a directory.

[0155] g) Fetch the directory listing for U; block 732.

[0156] h) Locate the entry in the directory listing corresponding topath element x_(s+i+1); block 734.

[0157] i) If no such entry exists, then stop, indicating failure; blocks736-738.

[0158] j) Let u′ be the obfuscated name of U/x_(s+i+1), theconcatenation of path U and element x_(s+i+1), as indicated in thedirectory entry; block 740.

[0159] k) Replace U with u′; Increment i by 1; blocks 742-744.

[0160] l) Continue executing the algorithm at step e), i.e. at block 728in FIG. 7b.

[0161] The obfuscated name u′ in step (j) is obtained by a table lookupin the directory listing fetched in step (g), which, in a previouslymentioned preferred embodiment, provides a mapping from the plain namesof all the resources in the directory to the corresponding obfuscatednames.

Publication of Signatures for Signed Published Content

[0162] In various embodiments, one or more of the published resources114 may be signed, and publication of the signatures is supported.Signing of the published resources 114 and making the signaturesavailable to the resource consuming peer systems 102 facilitates theresource consuming systems 102 in assuring the authenticity of theretrieved resources 114, including in the case where said resources 114are retrieved not from their original publisher 102 but from a cachingpeer system 102.

[0163] In one embodiment, upon publication of a resource 114, CAC client110 (more specifically, RPA function 136) automatically computes atime-stamped and versioned electronic signature for the resource 114based on its plaintext, and using the signing key S_(pr) 119 of the peersystem 102. The signature is then made available to the consuming peersystems 102 as follows:

[0164] for a resource 114 that has a directly associated RKF 116, thesignature is added to the RKF 116 of the resource 114;

[0165] for resources 114 having an inherited RKF 116, the signature isadded next to the resource's entry in the directory listing of theparent directory of the resource 114.

[0166] In alternate embodiments, for efficiency reasons, ordinarynon-keyed hashes (such as MD5 or SHA-1) may be substituted forsignatures in either of the above cases. Recall that the resource keyfile 116 of a resource 114 may be signed as a whole with the publisherpeer system's signature. Accordingly, as those skilled in the artr willappreciate, the hash will be authenticated. The substitution is alsoacceptable for Directory Listings with a directly associated RKF 116,since a Directory Listing as a whole may itself be validated by a hashin a signed resource key file 116, or for published directories with aninherited RKF 116, via a chain of hashes in ancestor Directory Listings,originating from a signed resource key file 116.

[0167] In alternate embodiments, the signature may be directly appendedas meta-data to the encrypted resource itself.

Resource Searching with Access Permissions

[0168] In various embodiments, support is provided to enable aconventional search engine to operate under the present invention, in amanner that is efficient and preserves the access permissions topublished resources when displaying search results.

[0169] In one embodiment, the secure crawling of published resources 114is made possible by including with each resource key file 116 of aresource 114 that the search engine crawler is permitted to access, anentry of the resource key 120 encrypted using the encryption public key(“Crawler Key”) of the search engine crawler. In various embodiments, asearch engine crawler will thus be authorized to access almost allpublished resources, except for a minority of extremely sensitiveresources 114.

[0170] In view of the general expectation that a search engine crawlerbe authorized to access virtually all published resources, accordinglythe present invention advantageously exercises care to avoid havingsensitive information be inadvertently revealed.

[0171] In various embodiments, this filtering of results, based on theaccess permissions of the peer system 102 performing the search, isachieved through “centralized search filtering”. For this embodiment, acentralized search filter (not shown) is additionally provided. Thecentralized search filter is provided with access to the user's privatedecryption key K_(pr) 115, e.g. as earlier described for a WebGate. Thesearch results are filtered by the search filter, before they arereturned to the user of a peer system 102.

[0172] In one embodiment, the centralized search filter operates asfollows, shown in FIG. 13a:

[0173] 1. A querying peer system 102 first authenticates itself with thesearch engine filter (SEF); block 1302. Any approach known to thoseskilled in the art may be used to authenticate querying peer system 102.

[0174] 2. The SEF, upon successful authentication, obtains the peersystem's keys (e.g. from the earlier described UKDB 1110), K_(pu) 113and K_(pr) 115; block 1304.

[0175] 3. The querying peer system 102 submits a query to the SEF; block1306.

[0176] 4. The SEF processes the query by passing it on to the searchengine as a regular search engine query (i.e. without enforcing anyaccess permissions), and internally obtains an ordered list of “hits”;block 1308.

[0177] 5. The SEF then proceeds to examining the highest ranked hits, upto a predetermined number; block 1310. For each high rank hit examined:

[0178] a) The SEF attempts to access the corresponding publishedresource 114, using the same method and the same peer system keys K_(pu)113 and K_(pr) 115 as the CAC client 110 would, in a manner similar toaccessing through the WebGate, described in “WebGate Access”.

[0179] b) If the access attempt was successful (i.e. the querying peersystem 102 has access permissions to the hit), the hit is retained inthe result list; otherwise it is discarded.

[0180] 6. The resultant list is then presented to the querying peersystem 102; block 1312.

[0181] In an alternate embodiment, filtering is not performed by a SEFthat needs to have access to the keys K_(pu) 113 and K_(pr) 115 of thequerying peer systems 102. Instead, access control is enforced by anEncryption Based Filter (EBF), in a manner similar to the one describedabove for resources, by encrypting each search hit with the resource key120 of the hit resource (i.e. encryption based search filtering). Morespecifically, each link in the search result is separately encryptedwith the same resource key 120 as the published resource 114 it linksto, which the EBF retrieves by decrypting the appropriate resource keyfile 116 of the published resource 114. For the embodiment, the contentof that resource key file 116 is returned in-line with the results—asopposed to the identification of the resource key file 116.

[0182] For the embodiment, the following additional precautions are alsotaken to reduce the possibility of information leakage:

[0183] a) A variable number of “fake” hit/resource key file pairs areincluded in each search result, constructed to look just like genuinehit/resource key file pairs. These “fake” pairs are constructedpseudo-randomly so as to be reproducible from one query to the next.

[0184] b) The search engine/filter always returns the user-requestednumber of hits, even if fewer actual hits are present. (The complementis faked as earlier described.)

[0185] c) The recipient peer systems 102 or groups 900 listed in theresource key files 116 are scrambled by encrypting their names withtheir own public encryption keys K_(pu) 113 or Group K_(pu) 912 (alongwith some pseudo-random content). This ensures that only authorized peersystems or group members can recognize a valid resource key file 116from a fake one.

[0186]FIG. 13b illustrates the operation flow, in accordance with oneembodiment. As illustrated:

[0187] 1. A querying peer system 102 first anonymously submits a queryto the Encryption-Based Filter (EBF), using its CAC client 110 (or theWebGate 1106); block 1322.

[0188] 2. The EBF processes the query, by passing it on to the searchengine as a regular search engine query (i.e. without enforcing anyaccess permissions), and internally obtains an ordered list of “hits”;block 1324.

[0189] 3. The EBF then inserts fake hit markers at random places in thehit list, after which the list in truncated to a fixed number of(genuine or fake) hits; block 1326.

[0190] 4. For each genuine hit in the remaining internal list, the EBFretrieves the relevant resource key files 116 for the resource 114corresponding to the hit, and prepares a result entry to comprise (i)the hit name encrypted with the resource key 120 found in the resourcekey file 116, (ii) the contents of the resource key file 116 itself,where all recipients have been scrambled as outlined above; block 1328.

[0191] 5. For each fake hit marker in the internal list, the searchengine/filter prepares a fake result entry of pseudo-random content andlength; block 1330.

[0192] 6. The ordered list of result entries is returned to the queryingpeer system's 102 CAC Client 110 (or the WebGate 1106); block 1332.

[0193] 7. The CAC Client 110 on the querying peer system 102 then goesthrough each returned result entry and attempt to decrypt it using theenclosed RKF contents (based on the approach described in “AccessingPublished Resources with Access Control”), returning the successfullydecrypted entries to the querying peer 102.

[0194] In various embodiments, it may be desirable to make publishedresources 114 searchable by any peer system 102, even such peer systemsthat would not otherwise be granted access. For these embodiments, theuniversal searchability is facilitated through the provision of a searchencryption public key (“Search Key”), as the similar key provided for acrawler (“Crawler Key”). The publisher of a resource 114 specifies foreach resource key file 116 whether the Search Key should grant access tothe controlled resources 114. Then, during the actual search, the searchengine/filter (SEF) will retain such hits which are either accessible bythe querying peer system 102 (as described above), or searchable bydefault (using the Search Key).

[0195] Note that the approach also enables anonymous searches, for whichthe querying peer system 102 is not required to log on. In this case,only hits that are searchable by default are returned.

Example Computer System

[0196]FIG. 14 illustrates an exemplary computer system 1400 suitable foruse as a peer computing device 102 of FIG. 1 to practice the presentinvention. As shown, computer system 1400 includes one or moreprocessors 1402 and system memory 1404. Additionally, computer system1400 includes one or more mass storage devices 1406 (such as diskette,hard drive, CDROM and so forth), general purpose input/output interfaces1408 (for interfacing keyboard, cursor control devices and so forth),and communication interfaces 1410 (such as network interface cards,modems and so forth). The elements are coupled to each other via systembus 1412, which represents one or more buses. In the case of multiplebuses, they are bridged by one or more bus bridges (not shown). Each ofthese elements performs its conventional functions known in the art. Inparticular, system memory 1404 and mass storage 1406 are employed tostore a working copy and a permanent copy of the programminginstructions implementing the teachings of the present invention (i.e.CAC client 110). The permanent copy of the programming instructions maybe loaded into mass storage 1406 in the factory, or in the field,through a distribution medium (not shown) or through communicationinterface 1410 from a distribution server (not shown). The constitutionof these elements 1402-1412 are known, and accordingly will not befurther described.

Advantages

[0197] The advantages of the distributed, encryption-based accesscontrol methodology of the present invention include, but are notlimited to:

[0198] The correctness and integrity of the underlying cachinginfrastructure need not be trusted, as it plays no role in the securityproperties of the model. For example, download requests for cachedmaterial may be granted without any check. Furthermore, the underlyingcaching infrastructure can deliver its full potential in terms ofperformance, since no security-related operations are performed whenserving a cached resource.

[0199] In particular, the separation of access control and cachinggreatly simplifies the deployment of dedicated, unsecured cache serversin the underlying caching infrastructure, which proactively cache allpublished content to ensure round the clock availability.

[0200] The recipients of a resource, rather than the providers, do mostof the work in “enforcing” access rights, which is deemed much fairerfrom a user experience perspective. Indeed, the extra load incurred onthe user machine will be correlated to the user action of accessingremote resources, rather than unpredictably when resources are requestedby other users.

[0201] The effort of tracing nested group memberships rests on thebeneficiary of the transaction. Not only is this fairer, but it allowsthe beneficiary to cache the necessary access keys for future use.

[0202] Revocation of access rights and group membership is secure andeasy. It is achieved transparently by updating the appropriate accesskeys, upon removal of group members or resource recipients.

[0203] In particular, this mechanism ensures that updated access rightsare immediately in force for future publications, without the need forcumbersome on-line revocation servers.

[0204] Since all content is already encrypted for the purpose of accesscontrol, there is no need for secure communication channels betweenclients. This is especially important for dedicated cache servers, dueto the prohibitive setup time of SSL connections.

Modifications and Alterations

[0205] While the present invention has been described referencing theillustrated and above enumerated embodiments, the present invention isnot limited to these described embodiments. Numerous modification andalterations may be made, consistent with the scope of the presentinvention as set forth in the claims to follow.

Conclusion and Epilogue

[0206] Thus, a distributed and scalable method and apparatus forcontrolling access to published resources by peer systems in adistributed and scalable manner has been described. Since as illustratedearlier, the present invention may be practiced with modification andalteration within the spirit and scope of the appended claims, thedescription is to be regarded as illustrative, instead of beingrestrictive on the present invention.

What is claimed is:
 1. A computer implemented method comprising:receiving a first resource identification of a first resource to bepublished, and first peer system identifications of a first plurality ofpeer systems to be granted access to said first resource after itspublication; generating a first resource key for use to encrypt thefirst resource; obtaining first encryption public keys of said firstpeer systems to be granted access to said first resource after itspublication; generating a first resource key file for said firstresource, including generating for said first peer systems to be grantedaccess to said first resource after publication, entries of said firstresource key of the first resource encrypted using said retrieved firstencryption public keys of said first plurality of peer systems to begranted access to said first resource after publication; and publishingthe first resource encrypted with said first resource key, along withsaid first resource key file, for selective access by said firstplurality of peer systems.
 2. The method of claim 1, wherein said firstpeer system identifications of said first plurality of peer systems tobe granted access to said first resource after its publication comprisea first peer system identification individually identifying a first ofsaid first plurality of peer systems.
 3. The method of claim 2, whereinsaid first of said first plurality of peer systems is a user peersystem.
 4. The method of claim 2, wherein said first of said firstplurality of peer systems is a gateway separating an internal networkand external networks.
 5. The method of claim 2, wherein said first ofsaid first plurality of peer systems comprises a search engine.
 6. Themethod of claim 1, wherein said first peer system identifications ofsaid first plurality of peer systems to be granted access to said firstresource after its publication comprise a first group identificationcollectively identifying a first subset of said first plurality of peersystems.
 7. The method of claim 6, wherein said first groupidentification comprises a first peer system identification individuallyidentifying a first of said first plurality of peer systems.
 8. Themethod of claim 6, wherein said first group identification comprises asecond group identification collectively identifying a second subset ofsaid first subset of peer systems.
 9. The method of claim 8, whereinsaid second group identification comprises said first groupidentification.
 10. The method of claim 9, wherein said second subset ofsaid first subset of peer systems comprises peer systems of one user.11. The method of claim 1, wherein said first resource key is randomlygenerated.
 12. The method of claim 1, wherein said first resource key isa symmetric encryption key.
 13. The method of claim 1, wherein saidfirst resource key is deterministically generated from a seed.
 14. Themethod of claim 13, wherein said deterministic generation of said firstresource key comprises randomly generating and saving a seed value;initializing one or more operational constants to one or more integervalues; and applying one or more one way hash functions to the seedvalue for one or more series of times in view of the one or moreoperational constants to generate or contribute to the generation of thefirst resource key.
 15. The method of claim 14, wherein saidinitializing comprises initializing a first operational constant to aninteger value N; and said applying comprises applying a first one wayhash function to the seed value for a first series of times denoted bythe first operational constant.
 16. The method of claim 14, wherein saidinitializing comprises initializing at least a first and a secondoperational constant to a first and a second integer values N1 and N2,that functionally map to a third integer value N; and said applyingcomprises applying a first one way hash function to the seed value for afirst series of times in view of the first operational constant, andapplying said first and a second one way hash function to said seedvalue for a second and a third series of times in view of said first andsecond operational constants.
 17. The method of claim 1, wherein saidobtaining of first encryption public keys of said first plurality ofpeer systems to be granted access to said first resource after itspublication comprises accessing first client key files of said firstplurality of peer systems.
 18. The method of claim 17, wherein saidaccessing of first client key files of said first plurality of peersystems comprises accessing a first client key file of a first of saidfirst plurality of peer systems.
 19. The method of claim 17, whereinsaid accessing of first client key files of said first plurality of peersystems comprises accessing a first client key file of a first group ofsaid first plurality of peer systems.
 20. The method of claim 1, whereinsaid generating of a first resource key file for said first resource,including generating for said first plurality of peer systems to begranted access to said first resource after publication, entries of saidfirst resource key of the first resource encrypted using the retrievedfirst encryption public keys of the first plurality of peer systems tobe granted access to said first resource after publication comprisesgenerating a first entry of said first resource key of the firstresource encrypted using a first of the retrieved first encryptionpublic keys corresponding to a first of the first plurality of peersystems.
 21. The method of claim 20, wherein said first of said firstplurality of peer systems is a user peer system.
 22. The method of claim20, wherein said first of said first plurality of peer systems is agateway separating an internal network and external networks.
 23. Themethod of claim 20, wherein said first of said first plurality of peersystems comprises a search engine.
 24. The method of claim 1, whereinsaid generating of a first resource key file for said first resource,including generating for said first plurality of peer systems to begranted access to said first resource after publication, entries of saidfirst resource key of the first resource encrypted using the retrievedfirst encryption public keys of the first plurality of peer systems tobe granted access to said first resource after publication comprisesgenerating a first entry of said first resource key of the firstresource encrypted using a first of the retrieved first encryptionpublic keys corresponding to a first group of the first plurality ofpeer systems.
 25. The method of claim 1, wherein at least one of saidgenerations of encrypted resource keys comprises encrypting theencrypted resource key one or more further times with a password. 26.The method of claim 1, wherein said publishing of the first resourcecomprises notifying a resource locator server of the availability of thefirst resource and the associated first resource key file for access byauthorized grantee systems including providing said resource locatorserver with said first resource identification of the first resource anda second resource identification identifying the associated firstresource key file.
 27. The method of claim 1, wherein said generating ofthe first resource key file further comprises generating an entry of anobfuscated identification of the first resource encrypted using thefirst resource key; and said publishing of the first resource comprisesnotifying a resource locator server of the availability of the firstresource and the associated first resource key file for access byauthorized grantee systems including providing said resource locatorserver with a first obfuscated identification of the first resource anda second resource identification identifying the associated firstresource key file.
 28. The method of claim 1, wherein the method furthercomprises generating a first access control list for the first resourceincluding said first peer system identifications of said first pluralityof peer systems, and said first resource key.
 29. The method of claim 1,wherein the method further comprises receiving from a peer system arequest for the first resource key file of the first resource; andproviding in response to the requesting peer system said first resourcekey file of the first resource.
 30. The method of claim 1, wherein themethod further comprises receiving from a peer system a request for thefirst resource, with the first resource being referenced by said firstresource identification; and providing in response to the requestingpeer system said first resource in an encrypted form, said firstresource being published under said first resource identification. 31.The method of claim 1, wherein the method further comprises receivingfrom a peer system a request for the first resource, with the firstresource being referenced by said first resource identification; andproviding in response to the requesting peer system said first resourcekey file of the first resource, said first resource being publishedunder a first obfuscated identification.
 32. The method of claim 1,wherein the method further comprises receiving from a peer system arequest for the first resource, with the first resource being referencedby a first obfuscated identification under which the first resource ispublished; and providing in response to the requesting peer system saidfirst resource in an encrypted form.
 33. The method of claim 1, whereinthe method further comprises encrypting said first resource using saidfirst resource key.
 34. The method of claim 1, wherein said firstresource is a selected one of a directory, a sub-directory, a data fileand an executable.
 35. The method of claim 1, wherein said firstresource is a selected one of a directory and a sub-directory, and themethod further comprises receiving from a peer system a request for asecond resource that is a member of the first directory/sub-directoryresource; and providing in response to the requesting peer system therequested second resource encrypted using said first resource key of thefirst resource, said second resource not having an associated resourcekey file, and said first resource being the closest ancestor resourcehaving an associated resource key file.
 36. The method of claim 1,wherein said first resource is a selected one of a directory and asub-directory, and the method further comprises receiving a secondresource identification of a second resource to be published, and secondpeer system identifications of a second plurality of peer systems to begranted access to said second resource after its publication, saidsecond resource being a member of said first directory/sub-directoryresource; generating a second resource key for use to encrypt the secondresource; obtaining second encryption public keys of said second peersystems to be granted access to said second resource after itspublication; generating a second resource key file for said secondresource, including generating for said second peer systems to begranted access to said second resource after publication, entries ofsaid second resource key of the second resource encrypted using saidretrieved second encryption public keys of said second plurality of peersystems to be granted access to said second resource after publication;and publishing the second resource, along with said second resource keyfile, for selective access by said second plurality of peer systems; 37.The method of claim 36, wherein the method further comprises receivingfrom a peer system a request for the second resource key file of thesecond resource; and providing in response to the requesting peer systemsaid second resource key file of the second resource.
 38. The method ofclaim 36, wherein the method further comprises receiving from a peersystem a request for the second resource, with the second resource beingcorrectly referenced; and providing in response to the requesting peersystem said second resource encrypted using said second resource key.39. The method of claim 1, wherein the method further comprisesgenerating a selected one of a first signature and a first hash value ofthe first resource for a first peer system using a first signing privatekey of the first peer system; and adding said selected one of the firstsignature and the first hash value to said first resource key file. 40.The method of claim 39, wherein the method further comprises encryptingsaid selected one of the first signature and the first hash value usingsaid first resource key of the first resource; and said adding comprisesadding said encrypted selected one of the first signature and the hashvalue to said first resource key file.
 41. The method of claim 1,wherein the method further comprises generating a selected one of afirst signature and a first hash value of a second resource, descendantof said first resource, for a first peer system using a first signingprivate key of the first peer system; and adding said selected one ofthe first signature and the first hash value to said first resource keyfile.
 42. The method of claim 41, wherein the method further comprisesencrypting said selected one of the first signature and the first hashvalue using said first resource key of the first resource; and saidadding comprises adding said encrypted selected one of the firstsignature and the first hash value to said first resource key file. 43.A computer implemented method to generate a resource key for a resourceto be published, comprising: randomly generating and saving a seedvalue; initializing one or more operational constants to one or moreinteger values; and applying one or more one way hash functions to theseed value for one or more series of times in view of the one or moreoperational constants to generate or contribute to the generation of theresource key.
 44. The method of claim 43, wherein said initializingcomprises initializing a first operational constant to an integer valueN; and said applying comprises applying a first one way hash function tothe seed value for a first series of times denoted by the firstoperational constant.
 45. The method of claim 43, wherein saidinitializing comprises initializing at least a first and a secondoperational constant to a first and a second integer values N1 and N2,that functionally map to a third integer value N; and said applyingcomprises applying a first one way hash function to the seed value for afirst series of times in view of the first operational constant, andapplying said first and a second one way hash function to said seedvalue for a second and a third series of times in view of said first andsecond operational constants.
 46. A computer implemented method forgenerating a resource key file for a resource to be published in anencrypted form, the method comprising obtaining encryption public keysof a plurality of peer systems to be granted access to said resourceafter its publication in said encrypted form; generating a plurality ofencrypted resource key entries by encrypting a resource key of saidresource encrypted using corresponding ones of said obtained encryptionpublic keys of said plurality of peer systems.
 47. The method of claim46, wherein said plurality of peer systems comprise a user peer system.48. The method of claim 46, wherein said plurality of peer systemscomprise a gateway separating an internal network and external networks.49. The method of claim 46, wherein said plurality of peer systemscomprise a search engine.
 50. The method of claim 46, wherein saidobtained encryption public keys comprise a group encryption public keyfor a subset of said plurality of peer systems which are members of agroup.
 51. The method of claim 46, wherein the method further comprisesgenerating a selected of a signature and a hash value of the resourcefor a peer system using a signing private key of the peer system; andadding said selected on of said signature and said hash value to saidresource key file.
 52. The method of claim 51, wherein the methodfurther comprises the method further comprises encrypting said selectedone of the signature and the hash value using said resource key of theresource; and said adding comprises adding said encrypted selected oneof the signature and the hash value to said resource key file.
 53. Themethod of claim 46, wherein the method further comprises generating aselected one of a signature and a hash value of a descendant resource ofsaid resource for a peer system using a signing private key of the peersystem; adding said selected one of said signature and said hash valueto said resource key file.
 54. The method of claim 53, wherein themethod further comprises the method further comprises encrypting saidselected one of the signature and the hash value using said resource keyof the resource; and said adding comprises adding said encryptedselected one of the signature and the hash value to said resource keyfile.
 55. A computer implemented method comprising generating anencryption private key for a group in a deterministic manner from arandom seed; generating a corresponding encryption public key for thegroup; publishing the corresponding encryption public key in a clientkey file for use by resource publishers to effectively grant access toresources published by the resource publishers to members of the group;and publishing the deterministically generated encryption private key ofthe group for members of the group to access authorized publishedresources.
 56. The method of claim 55, wherein said generating of anencryption private key for a group in a deterministic manner comprisesgenerating and saving a random seed value; initializing one or moreoperational constants to one or more integer values; and applying one ormore one way hash functions to the seed value for one or more series oftimes in view of the one or more operational constants to generate orcontribute to the generation of the encryption private key for thegroup.
 57. The method of claim 56, wherein said initializing comprisesinitializing a first operational constant to an integer value N; andsaid applying comprises applying a first one way hash function to theseed value for a first series of times denoted by the first operationalconstant.
 58. The method of claim 56, wherein said initializingcomprises initializing at least a first and a second operationalconstant to a first and a second integer values N1 and N2, thatfunctionally map to a third integer value N; and said applying comprisesapplying a first one way hash function to the seed value for a firstseries of times in view of the first operational constant, and applyingsaid first and a second one way hash function to said seed value for asecond and a third series of times in view of said first and secondoperational constants.
 59. The method of claim 55, wherein said methodfurther comprises re-generating the encryption public and private keysof the group when a member is removed from the group; and re-publishingthe re-generated encryption public and private keys of the group for useby resource publishers and members of the group respectively.
 60. Themethod of claim 59, wherein said initial generating of an encryptionprivate key for a group in a deterministic manner comprises randomlygenerating and saving a seed value and an associated operationalvariable N, initialized to a constant, and applying a one way hashfunction to the seed value for a number of times as specified by thecurrent value of the operational variable to generate the encryptionprivate key of the group; and said re-generating of the encryptionprivate key for the group comprises decrementing the operationalvariable in a pre-determine manner, and applying the one way hashfunction to the seed value for a number of times as specified by thecurrent value of the operational constant to re-generate the encryptionprivate key of the group.
 61. The method of claim 59, wherein saidpublishing of the deterministically generated encryption private key ofthe group for members of the group to access authorized publishedresources comprises retrieving a first encryption public key of a firstmember, generating a first encrypted entry of the group's encryptionprivate key using the retrieved first encryption public key of the firstmember, and placing the generated first encrypted entry into a group keyfile.
 62. The method of claim 61, wherein said publishing of thedeterministically generated encryption private key of the group formembers of the group to access authorized published resources furthercomprises repeating said retrieving, generating, and placing for eachmember.
 63. The method of claim 61, wherein said publishing of thedeterministically generated encryption private key of the group formembers of the group to access authorized published resources furthercomprises publishing the group key file.
 64. A computer implementedmethod comprising receiving from a peer system a request for a resourcepublished in an obfuscated manner; providing in response to therequesting peer system said requested resource in an encrypted form, ifsaid request references said resource by its obfuscated identification.65. The method of claim 64, wherein the method further comprisesproviding in response to the requesting peer system a resource key fileof the resource, if said request references said resource by its plainidentification.
 66. A peer system comprising: storage medium havingstored therein a plurality of programming instructions designed toenable the peer system to receive a first resource identification of afirst resource to be published, and first peer system identifications ofa first plurality of other peer systems to be granted access to saidfirst resource after its publication, generate a first resource key foruse to encrypt the first resource; obtain first encryption public keysof said first other peer systems to be granted access to said firstresource after its publication, generate a first resource key file forsaid first resource, including generating for said first other peersystems to be granted access to said first resource after publication,entries of said first resource key of the first resource encrypted usingsaid retrieved first encryption public keys of said first plurality ofother peer systems to be granted access to said first resource afterpublication, and publish the first resource encrypted with said firstresource key, along with said first resource key file, for selectiveaccess by said first plurality of other peer systems; and a processorcoupled to the storage medium to execute the programming instructions.67. The peer system of claim 66, wherein said first peer systemidentifications of said first plurality of other peer systems to begranted access to said first resource after its publication comprise afirst peer system identification individually identifying a first ofsaid first plurality of other peer systems.
 68. The peer system of claim67, wherein said first of said first plurality of other peer systems isa user peer system.
 69. The peer system of claim 67, wherein said firstof said first plurality of other peer systems is a gateway separating aninternal network and external networks.
 70. The peer system of claim 67,wherein said first of said first plurality of other peer systemscomprises a search engine.
 71. The peer system of claim 66, wherein saidfirst peer system identifications of said first plurality of peersystems to be granted access to said first resource after itspublication comprise a first group identification collectivelyidentifying a first subset of said first plurality of other peersystems.
 72. The peer system of claim 71, wherein said first groupidentification comprises a first peer system identification individuallyidentifying a first of said first plurality of other peer systems. 73.The peer system of claim 71, wherein said first group identificationcomprises a second group identification collectively identifying asecond subset of said first subset of peer systems.
 74. The peer systemof claim 73, wherein said second group identification comprises saidfirst group identification.
 75. The peer system of claim 74, whereinsaid second subset of said first subset of peer systems comprises peersystems of one user.
 76. The peer system of claim 66, wherein said firstresource key is randomly generated.
 77. The peer system of claim 66,wherein said first resource key is a symmetric encryption key.
 78. Thepeer system of claim 66, wherein said first resource key isdeterministically generated from a seed.
 79. The peer system of claim78, wherein said programming instructions are designed to enable thepeer system to perform said deterministic generation of said firstresource key by randomly generating and saving a seed value;initializing one or more operational constants to one or more integervalues; and applying one or more one way hash functions to the seedvalue for one or more series of times in view of the one or moreoperational constants to generate or contribute to the generation of thefirst resource key.
 80. The peer system of claim 79, wherein saidprogramming instructions are designed to enable the peer system toperform said initializing by initializing a first operational constantto an integer value N; and said applying by applying a first one wayhash function to the seed value for a first series of times denoted bythe first operational constant.
 81. The peer system of claim 79, whereinsaid programming instructions are designed to enable the peer system toperform said initializing by initializing at least a first and a secondoperational constant to a first and a second integer values N1 and N2,that functionally map to a third integer value N; and said applying byapplying a first one way hash function to the seed value for a firstseries of times in view of the first operational constant, and applyingsaid first and a second one way hash function to said seed value for asecond and a third series of times in view of said first and secondoperational constants.
 82. The peers system of claim 66, wherein saidprogramming instructions are designed to enable the peer system toperform said obtaining of first encryption public keys of said firstplurality of other peer systems to be granted access to said firstresource after its publication by accessing first client key files ofsaid first plurality of other peer systems.
 83. The peer system of claim82, wherein said programming instructions are designed to enable thepeer system to perform said accessing of first client key files of saidfirst plurality of other peer systems by accessing a first client keyfile of a first of said first plurality of other peer systems.
 84. Thepeer system of claim 82, wherein said programming instructions aredesigned to enable the peer system to perform said accessing of firstclient key files of said first plurality of other peer systems byaccessing a first client key file of a first group of said firstplurality of other peer systems.
 85. The peer system of claim 66,wherein said programming instructions are designed to enable the peersystem to perform said generating of a first resource key file for saidfirst resource, including generating for said first plurality of otherpeer systems to be granted access to said first resource afterpublication, entries of said first resource key of the first resourceencrypted using the retrieved first encryption public keys of the firstplurality of other peer systems to be granted access to said firstresource after publication by generating a first entry of said firstresource key of the first resource encrypted using a first of theretrieved first encryption public keys corresponding to a first of thefirst plurality of other peer systems.
 86. The peer system of claim 85,wherein said first of said first plurality of other peer systems is auser peer system.
 87. The peer system of claim 85, wherein said first ofsaid first plurality of other peer systems is a gateway separating aninternal network and external networks.
 88. The peer system of claim 85,wherein said first of said first plurality of other peer systemscomprises a search engine.
 89. The peer system of claim 86, wherein saidprogramming instructions are designed to enable the peer system toperform said generating of a first resource key file for said firstresource, including generating for said first plurality of other peersystems to be granted access to said first resource after publication,entries of said first resource key of the first resource encrypted usingthe retrieved first encryption public keys of the first plurality ofother peer systems to be granted access to said first resource afterpublication by generating a first entry of said first resource key ofthe first resource encrypted using a first of the retrieved firstencryption public keys corresponding to a first group of the firstplurality of other peer systems.
 90. The peer system of claim 66,wherein said programming instructions are designed to enable the peersystem to perform at least one of said generations of encrypted resourcekeys by encrypting the encrypted resource key one or more further timeswith a password.
 91. The peer system of claim 66, wherein saidprogramming instructions are designed to enable the peer system toperform said publishing of the first resource by notifying a resourcelocator server of the availability of the first resource and theassociated first resource key file for access by authorized granteesystems including providing said resource locator server with said firstresource identification of the first resource and a second resourceidentification identifying the associated first resource key file. 92.The peer system of claim 65, wherein said programming instructions aredesigned to enable the peer system to perform said generating of thefirst resource key file by further generating an entry of an obfuscatedidentification of the first resource encrypted using the first resourcekey; and said publishing of the first resource by notifying a resourcelocator server of the availability of the first resource and theassociated first resource key file for access by authorized granteesystems including providing said resource locator server with a firstobfuscated identification of the first resource and a second resourceidentification identifying the associated first resource key file. 93.The peer system of claim 66, wherein said programming instructions arefurther designed to enable the peer system to generate a first accesscontrol list for the first resource including said first peer systemidentifications of said first plurality of other peer systems, and saidfirst resource key.
 94. The peer system of claim 66, wherein saidprogramming instructions are further designed to enable the peer systemto receive from a first of said first plurality of other peer systems arequest for the first resource key file of the first resource; andprovide in response to the requesting first other peer system said firstresource key file of the first resource.
 95. The peer system of claim66, wherein said programming instructions are further designed to enablethe peer system to receive from a first of said first plurality of otherpeer systems a request for the first resource, with the first resourcebeing referenced by said first resource identification; and provide inresponse to the requesting first other peer system said first resourcein an encrypted form, said first resource being published under saidfirst resource identification.
 96. The peer system of claim 66, whereinsaid programming instructions are further designed to enable the peersystem to receive from a first of the first plurality of other peersystems a request for the first resource, with the first resource beingreferenced by said first resource identification; and provide inresponse to the requesting first other peer system said first resourcekey file of the first resource, said first resource being publishedunder a first obfuscated identification.
 97. The peer system of claim66, wherein said programming instructions are further designed to enablethe peer system to receive from a first of the first plurality of otherpeer systems a request for the first resource, with the first resourcebeing referenced by a first obfuscated identification under which thefirst resource is published; and provide in response to the requestingfirst other peer system said first resource in an encrypted form. 98.The peer system of claim 66, wherein said programming instructions arefurther designed to enable the peer system to encrypt said firstresource using said first resource key.
 99. The peer system of claim 66,wherein said first resource is a selected one of a directory, asub-directory, a data file and an executable.
 100. The peer system ofclaim 66, wherein said first resource is a selected one of a directoryand a sub-directory, and said programming instructions are furtherdesigned to enable the peer system to receive from a first of the firstplurality of other peer systems a request for a second resource that isa member of the first directory/sub-directory resource; and provide inresponse to the requesting the first other peer system the requestedsecond resource encrypted using said first resource key of the firstresource, said second resource not having an associated resource keyfile, and said first resource being the closest ancestor resource havingan associated resource key file.
 101. The peer system of claim 66,wherein said first resource is a selected one of a directory and asub-directory, and said programming instructions are further designed toenable the peer system to receive a second resource identification of asecond resource to be published, and second peer system identificationsof a second plurality of other peer systems to be granted access to saidsecond resource after its publication, said second resource being amember of said first directory/sub-directory resource; generate a secondresource key for use to encrypt the second resource; obtain secondencryption public keys of said second other peer systems to be grantedaccess to said second resource after its publication; generate a secondresource key file for said second resource, including generating forsaid second other peer systems to be granted access to said secondresource after publication, entries of said second resource key of thesecond resource encrypted using said retrieved second encryption publickeys of said second plurality of other peer systems to be granted accessto said second resource after publication; and publish the secondresource, along with said second resource key file, for selective accessby said second plurality of other peer systems;
 102. The peer system ofclaim 101, wherein said programming instructions are further designed toenable the peer system to receive from a first of said first pluralityof other peer systems a request for the second resource key file of thesecond resource; and provide in response to the requesting first otherpeer system said second resource key file of the second resource. 103.The peer system of claim 101, wherein said programming instructions arefurther designed to enable the peer system to receive from a first ofsaid first plurality of other peer systems a request for the secondresource, with the second resource being correctly referenced; andprovide in response to the requesting first other peer system saidsecond resource encrypted using said second resource key.
 104. The peersystem of claim 66, wherein said programming instructions are furtherdesigned to enable the peer system to generate a selected one of a firstsignature and a first hash value of the first resource for a first otherpeer system using a first signing private key of the first other peersystem; and add said selected one of the first signature and the firsthash value to said first resource key file.
 105. The peer system ofclaim 104, wherein said programming instructions are further designed toenable the peer system to encrypt said selected one of the firstsignature and the first hash value using said first resource key of thefirst resource; and perform said adding by adding said encryptedselected one of the first signature and the hash value to said firstresource key file.
 106. The peer system of claim 66, wherein saidprogramming instructions are further designed to enable the peer systemto generate a selected one of a first signature and a first hash valueof a second resource, descendant of said first resource, for a firstother peer system using a first signing private key of the first otherpeer system; and add said selected one of the first signature and thefirst hash value to said first resource key file.
 107. The peer systemof claim 106, wherein said programming instructions are further designedto enable the peer system to encrypt said selected one of the firstsignature and the first hash value using said first resource key of thefirst resource; and perform said adding by adding said encryptedselected one of the first signature and the first hash value to saidfirst resource key file.
 108. A peer system comprising: storage mediumhaving stored therein a plurality of programming instructions designedto enable the peer system to randomly generate and saving a seed value;initialize one or more operational constants to one or more integervalues; and apply one or more one way hash functions to the seed valuefor one or more series of times in view of the one or more operationalconstants to generate or contribute to the generation of the resourcekey; and at least one processor coupled to the storage medium to executethe programming instructions.
 109. The peer system of claim 108, whereinsaid programming instructions are further designed to enable the peersystem to perform said initializing by initializing a first operationalconstant to an integer value N; and said applying by applying a firstone way hash function to the seed value for a first series of timesdenoted by the first operational constant.
 110. The peer system of claim108, wherein said programming instructions are further designed toenable the peer system to perform said initializing by initializing atleast a first and a second operational constant to a first and a secondinteger values N1 and N2, that functionally map to a third integer valueN; and said applying by applying a first one way hash function to theseed value for a first series of times in view of the first operationalconstant, and applying said first and a second one way hash function tosaid seed value for a second and a third series of times in view of saidfirst and second operational constants.
 111. A peer system comprising:storage medium having stored therein a plurality of programminginstructions designed to enable the peer system to obtain encryptionpublic keys of a plurality of other peer systems to be granted access tosaid resource after its publication in said encrypted form, and generatea plurality of encrypted resource key entries by encrypting a resourcekey of said resource encrypted using corresponding ones of said obtainedencryption public keys of said plurality of other peer systems; and atleast one processor coupled to the storage medium to execute theprogramming instructions.
 112. The peer system of claim 111, whereinsaid plurality of other peer systems comprise a user peer system. 113.The peer system of claim 111, wherein said plurality of other peersystems comprise a gateway separating an internal network and externalnetworks.
 114. The peer system of claim 111, wherein said plurality ofother peer systems comprise a search engine.
 115. The peer system ofclaim 111, wherein said obtained encryption public keys comprise a groupencryption public key for a subset of said plurality of other peersystems which are members of a group.
 116. The peer system of claim 111,wherein said programming instructions are further designed to enable thepeer system to generate a selected of a signature and a hash value ofthe resource for a first of said other peer systems using a signingprivate key of the first other peer system; and add said selected on ofsaid signature and said hash value to said resource key file.
 117. Thepeer system of claim 116, wherein said programming instructions arefurther designed to enable the peer system to encrypt said selected oneof the signature and the hash value using said resource key of theresource; and perform said adding by adding said encrypted selected oneof the signature and the hash value to said resource key file.
 118. Thepeer system of claim 111, wherein said programming instructions arefurther designed to enable the peer system to generate a selected one ofa signature and a hash value of a descendant resource of said resourcefor a first of said other peer systems using a signing private key ofthe first other peer system; and add said selected one of said signatureand said hash value to said resource key file.
 119. The peer system ofclaim 118, wherein said programming instructions are further designed toenable the peer system to encrypt said selected one of the signature andthe hash value using said resource key of the resource; and perform saidadding comprises adding said encrypted selected one of the signature andthe hash value to said resource key file.
 120. A peer system comprising:storage medium having stored therein a plurality of programminginstructions designed to enable the peer system to generate anencryption private key for a group in a deterministic manner from arandom seed, generate a corresponding encryption public key for thegroup, publish the corresponding encryption public key in a client keyfile for use by resource publishers to effectively grant access toresources published by the resource publishers to members of the group,and publish the deterministically generated encryption private key ofthe group for members of the group to access authorized publishedresources; at least one processor coupled to the storage medium toexecute the programming instructions.
 121. The peer system of claim 120,wherein said programming instructions are further designed to enable thepeer system to perform said generating of an encryption private key fora group in a deterministic manner by generating and saving a random seedvalue; initializing one or more operational constants to one or moreinteger values; and applying one or more one way hash functions to theseed value for one or more series of times in view of the one or moreoperational constants to generate or contribute to the generation of theencryption private key for the group.
 122. The peer system of claim 121,wherein said programming instructions are further designed to enable thepeer system to perform said initializing by initializing a firstoperational constant to an integer value N; and said applying byapplying a first one way hash function to the seed value for a firstseries of times denoted by the first operational constant.
 123. The peersystem of claim 121, wherein said programming instructions are furtherdesigned to enable the peer system to perform said initializing byinitializing at least a first and a second operational constant to afirst and a second integer values N1 and N2, that functionally map to athird integer value N; and said applying by applying a first one wayhash function to the seed value for a first series of times in view ofthe first operational constant, and applying said first and a second oneway hash function to said seed value for a second and a third series oftimes in view of said first and second operational constants.
 124. Thepeer system of claim 120, wherein said programming instructions arefurther designed to enable the peer system to re-generate the encryptionpublic and private keys of the group when a member is removed from thegroup; and re-publish the re-generated encryption public and privatekeys of the group for use by resource publishers and members of thegroup respectively.
 125. The peer system of claim 124, wherein saidprogramming instructions are further designed to enable the peer systemto perform said initial generating of an encryption private key for agroup in a deterministic manner by randomly generating and saving a seedvalue and an associated operational variable N, initialized to aconstant, and applying a one way hash function to the seed value for anumber of times as specified by the current value of the operationalvariable to generate the encryption private key of the group; and saidre-generating of the encryption private key for the group bydecrementing the operational variable in a pre-determine manner, andapplying the one way hash function to the seed value for a number oftimes as specified by the current value of the operational constant tore-generate the encryption private key of the group.
 126. The peersystem of claim 124, wherein said programming instructions are furtherdesigned to enable the peer system to perform said publishing of thedeterministically generated encryption private key of the group formembers of the group to access authorized published resources byretrieving a first encryption public key of a first member, generating afirst encrypted entry of the group's encryption private key using theretrieved first encryption public key of the first member, and placingthe generated first encrypted entry into a group key file.
 127. The peersystem of claim 126, wherein said programming instructions are furtherdesigned to enable the peer system to perform said publishing of thedeterministically generated encryption private key of the group formembers of the group to access authorized published resources by furtherrepeating said retrieving, generating, and placing for each member. 128.The peer system of claim 126, wherein said programming instructions arefurther designed to enable the peer system to perform said publishing ofthe deterministically generated encryption private key of the group formembers of the group to access authorized published resources further bypublishing the group key file.
 129. A peer system comprising storagemedium having stored therein a plurality of programming instructionsdesigned to enable the peer system to receive from another peer system arequest for a resource published in an obfuscated manner; provide inresponse to the requesting other peer system said requested resource inan encrypted form, if said request references said resource by itsobfuscated identification; and at least one processor coupled to thestorage medium to execute the programming instructions.
 130. The peersystem of claim 129, wherein said programming instructions are furtherdesigned to enable the peer system to provide in response to therequesting other peer system a resource key file of the resource, ifsaid request references said resource by its plain identification.